Flow-based packet transport device and packet management method thereof

ABSTRACT

Disclosed is a packet managing method of a packet forwarding device. The packet managing method includes receiving a packet; extracting flow information from the packet; searching a flow entry associated with the packet; and requesting the flow entry associated with the packet to a controller when a searching operation of the flow entry is failed. The request on the flow entry associated with the packet is not transferred within a reference time.

CROSS-REFERENCE TO RELATED APPLICATIONS

This U.S. non-provisional patent application claims priority under 35U.S.C. §119 to Korean Patent Application No. 10-2011-0142367, filed onDec. 26, 2011, the entirety of which is incorporated by referenceherein.

BACKGROUND

The inventive concept relates to communication network and, moreparticularly, to a flow-based packet forwarding device and a packetmanaging method thereof.

In recent years, network business environment may change suddenly due toexplosive increase in wireless data, caused by population of smartphones, and appearance of new types of application services such associal networks, clouds, smart televisions, and the like. Also, thenetwork may be requested to receive new and various requirements moreflexibly. Development on new network paradigm such as Software DefinedNetworking (SDN) may be proceeding actively.

The SDN may be new network technique capable of dynamically configuringand controlling a network dynamically according to various requirementsof the user and service without limitation of a conventional closednetwork service environment. With the SDN, a control plane of aconventional network device separated from a forwarding plane may becollected at a centralized controller to control a software-basednetwork overall. A typical example of the SDN may be the OpenFlownetwork.

In network system where control plane is separated from forwardingplane, packets arriving at forwarding device may be classified intoflows according to header information, and may be processed according tomatched flow entry searched at locally managed flow table.

If flow rule matching is failed, however, request for flow entry may beiteratively forwarded to the controller. In this case, load of thecontroller may increase, and bottleneck phenomenon of the controller maybe caused. That is, the network performance may be lowered generally.

SUMMARY

Embodiments of the inventive concept provide a packet managing method ofa packet forwarding device which comprises receiving a packet;extracting flow information from the packet; searching a flow entryassociated with the packet; and requesting the flow entry associatedwith the packet to a controller when a searching operation of the flowentry is failed, wherein the request on the flow entry associated withthe packet is not transferred within a reference time.

Embodiments of the inventive concept also provide a packet forwardingdevice comprising a flow search part searching a flow entry for areceived packet; a flow processing part processing the received packetaccording to a procedure corresponding to the searched flow entry; aflow table management part managing a flow entry for each of flows in aflow table; and a flow entry request processing part requesting the flowentry to a controller, based on whether a flow entry requestcorresponding to the same flow exists within a reference time withrespect to a receive packet that a searching operation of acorresponding flow entry by the flow search part is failed.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept will become more apparent in view of the attacheddrawings and accompanying detailed description.

FIG. 1 is a schematic diagram illustrating an OpenFlow network system.

FIG. 2 is a flow chart illustrating a packet managing method in anOpenFlow switch of FIG. 1;

FIG. 3 is a block diagram illustrating a packet forwarding deviceaccording to embodiments of the inventive concept;

FIG. 4 is a block diagram illustrating a flow entry request processingpart of FIG. 3; and

FIG. 5 is a flow chart illustrating a packet managing method of a packetforwarding device according to embodiments of the inventive concept.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The inventive concept will now be described more fully hereinafter withreference to the accompanying drawings, in which exemplary embodimentsof the inventive concept are shown. The advantages and features of theinventive concept and methods of achieving them will be apparent fromthe following exemplary embodiments that will be described in moredetail with reference to the accompanying drawings. It should be noted,however, that the inventive concept is not limited to the followingexemplary embodiments, and may be implemented in various forms.Accordingly, the exemplary embodiments are provided only to disclose theinventive concept and let those skilled in the art know the category ofthe inventive concept. In the drawings, embodiments of the inventiveconcept are not limited to the specific examples provided herein and areexaggerated for clarity.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to limit the invention. As usedherein, the singular terms “a,” “an” and “the” are intended to includethe plural forms as well, unless the context clearly indicatesotherwise. As used herein, the term “and/or” includes any and allcombinations of one or more of the associated listed items. It will beunderstood that when an element is referred to as being “connected” or“coupled” to another element, it may be directly connected or coupled tothe other element or intervening elements may be present.

Similarly, it will be understood that when an element such as a layer,region or substrate is referred to as being “on” another element, it canbe directly on the other element or intervening elements may be present.In contrast, the term “directly” means that there are no interveningelements. It will be further understood that the terms “comprises”,“comprising,”, “includes” and/or “including”, when used herein, specifythe presence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

OpenFlow proposed by the Open Network Foundation will be described withreference to a network system in which packet forwarding and controllingare separated. However, the inventive concept is not limited to thenetwork system.

FIG. 1 is a schematic diagram illustrating an OpenFlow network system.An OpenFlow network system may include a network 100, a controller 110,and a plurality of communication terminals 131, 132, and 133.

The network 100 may include a plurality of OpenFlow switches 121 to 126for providing destinations with packets forwarded from the communicationterminals 131 to 133. The OpenFlow switches 121 to 126 and thecontroller 110 may be mutually communicated using the OpenFlow protocol.

FIG. 2 is a flow chart illustrating a packet managing method of anOpenFlow switch in FIG. 1. Referring to FIG. 2, one OpenFlow switch (oneof 121 to 126) may process the packet provided from one of thecommunication terminals 131 to 133 according to the following method.

In step S110, the OpenFlow switch may receive the packet transferredfrom the communication terminal.

In step S120, the OpenFlow switch may extract flow information from thepacket.

In step S130, the OpenFlow switch may search whether a flow entrydescribing a processing procedure associated with a corresponding flowexists at a flow table. If the flow entry of the corresponding flowexists at the flow table, the method may proceed to step S140. If theflow entry of the corresponding flow does not exist at the flow table,the method may proceed to step S150.

In step S140, the OpenFlow switch may process the received packetaccording to the procedure described in the searched flow entry. Forexample, the OpenFlow switch may output the received packet to aspecific port, drop the received packet, or revise a specific headerfield according to the searched flow entry.

In step S150, the OpenFlow switch may transfer the whole received packetor a portion of the received packet necessary for extracting the flowinformation to the controller 110. The controller 110 may configure theflow entry corresponding to the received packet to transmit it to theOpenFlow switch. The OpenFlow switch may process the packet according tothe procedure defined with reference to the flow entry sent from thecontroller 110. Afterwards, the OpenFlow switch may update the flowtable based on the processed result.

At this time, a corresponding packet may be buffered by a memory on theOpenFlow switch for a constant time such that a flow entry provided fromthe controller 110 is added to the flow table and then is transferred.At this time, a packet belonging to a new flow may be transmitted to thecontroller 110.

A time taken until a corresponding flow entry is defined by thecontroller 110 and is set to the flow table may be referred to as areference time τ. Also, packets belonging to a specific flow Z may bereferred to as ρ1, ρ2, ρ3, . . . , ρn, respectively. After a firstreception packet ρ1 arrives at the controller 110, a packet receivedwithin the reference time τ may be sent to the controller 110 due tofailure of flow entry search.

As described above, at all the OpenFlow switches in the network 100, allthe failed packets to find matched flow entry will be converged to thecontroller 110. And, the packet processing load of the controller 110will increase. Eventually, the controller 110 may be a bottleneck pointof the whole network system. Additionally, since a lot of packets aretransmitted to the controller 110 during the reference time τ forsetting the new flow entry in a high speed network circumstance, theload applied to the controller 110 may become greater in proportion tothe number of the packets transmitted to the controller 110.

FIG. 3 is a block diagram illustrating a packet forwarding deviceaccording to embodiments of the inventive concept. A packet forwardingdevice 200 may include an OpenFlow switch described with reference toFIG. 1. Alternatively, the packet forwarding device 200 may be one ofvarious elements constituting a flow-based network besides the OpenFlowswitch. Referring to FIG. 3, the packet forwarding device 200 accordingto embodiments may reduce the number of repeated flow entry requests.The packet forwarding device 200 may include a flow search part 210, aflow processing part 220, a flow table management part 230, and a flowentry request processing part 240.

The flow search part 210 may extract flow information from a receivedpacket. The flow search part 210 may search a flow table (not shown)managed by the flow table management part 230, based on the extractedflow information. The flow search part 210 may search a flow entryassociated with the received packet. If the flow search part 210successfully searches the flow entry associated with the receivedpacket, the flow search part 210 may request the flow processing part220 to process the received packet according to the searched flow entry.If an operation of searching the flow entry is failed, the flow searchpart 210 may request the flow table request processing part 240 totransmit the received packet to a controller 300.

The flow processing part 220 may output the received packet to aspecific port, drop the received packet, or revise a specific headerfield according to a procedure described in the searched flow entry. Itis well understood that the procedure defined in the flow entry is notlimited to the above-described processes.

The flow table management part 230 may take full charge of management ofthe flow entries stored in the flow table. For example, the flow tablemanagement part 230 may periodically remove timeout flow entries. When anew flow entry is additionally requested from the flow entry requestprocessing part 240, the flow table management part 230 may add therequested new flow entry to the flow table.

When the flow search part 210 requests a new flow entry, the flow entryrequest processing part 240 may judge whether a packet corresponding tothe new flow entry is transferred to the controller 300 or not. In otherwords, if a failed packet occurs at a flow entry searching operation ofthe flow search part 210, the flow entry request processing part 240 mayjudge whether the packet is transferred to the controller 300 or not.The flow entry request processing part 240 may transfer a minimumquantity of data to the controller 300 according to the judgment result.Additionally, a new flow entry from the controller 300 is input, theflow entry request processing part 240 may send the new flow entry tothe flow table management part 230 to be added to the flow table.

To judge whether a packet for a request of a flow entry transferred fromthe flow search part 210 is sent to the controller 300 or not, the flowentry request processing part 240 may judge whether a packet in the sameflow was transferred to the controller 300 within a specific referencetime τ or not. The specific reference time τ may be determined dependingon a time from a time when a flow entry request packet is sent to thecontroller 300 until a time when a new flow entry is received from thecontroller 300. The specific reference time τ may be dynamically changedaccording to controller and network situations.

Even if the flow entry is not searched from the received packet, thepacket transport device 200 of the inventive concepts may not repeatedlyforward a flow entry request corresponding to the packet within thereference time τ. Thus, it is possible to prevent a bottleneckphenomenon caused when a flow entry request is iteratively transferred.Additionally, the load of the controller 300 may be reduced, so that aresource is efficiently used to manage the network.

FIG. 4 is a block diagram illustrating a flow entry request processingpart of FIG. 3. Referring to FIG. 4, a flow entry request processingpart 240 may include a flow entry request table 241, a flow entryrequest table management module 242, a flow entry search module 243, anda controller communication module 244.

When a new flow entry is requested from a flow search part 210 (refer toFIG. 3), the flow entry request table 241 may store and manageinformation used to judge whether a flow entry request associated withthe same flow was transferred to a controller 300 or not. Each flowentry stored in the flow entry request table 241 may be formed of a flowkey for distinguishing a flow and a timeout time. The flow entry requesttable 241 may exist separately from the flow table. Alternatively, theflow table may further include fields corresponding to a timeout pointand whether a flow entry is requested to the controller 300, as occasiondemands. The field indicating whether a flow entry is requested may bedata indicating whether a flow entry request message is transferred tothe controller 300, and a timeout time field may be data indicating howlong a response to a flow entry request is waited.

The flow entry request table management module 242 may periodicallyremove timeout flow entries of the flow entries in the flow entryrequest table 241. When a new flow entry request is transferred to thecontroller 300, the flow entry request table management module 242 mayadd an entry having a corresponding flow used as a flow key and atimeout time (a current time+the reference time τ) to the flow entryrequest table 241. The reference time τ may be determined depending onan average time from a time when the flow entry request message istransferred to the controller until a time when a response reply isreceived.

Whenever the flow entry search module 243 receives a new flow entryrequest, it may search the flow entry request table 241 to judgetransferring of the request to the controller 300. If a matched entryexists in the flow entry request table 241, a request associated withthe new flow entry may be reserved. If no matched entry exists in theflow entry request table 241, the entry search module 243 may requestthe flow entry request table management module 242 to add a flow requestentry. And the flow entry search module 243 may transmit a flow entryrequest to the controller 300 through the controller communicationmodule 244.

If the flow entry search module 243 does not receive the requested flowentry from the controller 300 within the reference time τ, the reservedflow entry may be again requested after a time elapses. The reason maybe that the flow entry request table management module 242 checks thetimeout time of each flow entry to periodically remove timeout flowentries.

The controller communication module 244 may transfer a flow entryrequest to the controller 300 under the control of the flow entry searchmodule 243.

As described above, the flow entry request message may not be repeatedlytransferred to the controller 300 through the flow entry requestprocessing part 240 within the reference time τ. Thus, it is possible tosave a communication resource and to prevent the load of the controller300 due to processing of unnecessary requests.

FIG. 5 is a flow chart illustrating a packet managing method of a packetforwarding device according to embodiments of the inventive concept.Referring to FIG. 5, a packet forwarding device 200 of FIG. 3 does notrepeatedly send a flow entry request associated with the same flow to acontroller 300 within a reference time τ.

In step S210, the packet forwarding device 200 receives a packet.

In step S220, the packet forwarding device 200 extracts flow informationfrom the packet.

In step S230, the packet forwarding device 200 searches whether a flowentry describing a flow processing procedure exists at a flow table. Ifthe flow entry of the corresponding flow exists at the flow table, themethod proceeds to step S240. When the flow entry of the correspondingflow does not exist at the flow table, the method proceeds to step S250.

In step S240, the packet forwarding device 200 may process the receivedpacket by the procedure described in the searched flow entry. Forexample, the packet forwarding device 200 may output the received packetto a specific port, drop the received packet, or revise a specificheader field according to the searched flow entry.

The step S250 may be divided into steps S252, S254, S256, and S258.

In step S252, there may be checked whether a flow entry requestassociated with the same flow was transferred to the controller 300 ornot. For example, this operation may be understood as an operation ofsearching a flow entry request table 241 as described with reference toFIG. 4.

In step S254, whether flow entry request is transferred within areference time τ may be judged. If the flow entry associate with thesame flow is requested to the controller 300 before the reference timeτ, the method proceeds to step S256. If the flow entry associated withthe same flow is not requested before the reference time τ, the methodproceeds to step S258.

In step S256, since the flow entry associated with the same flow isrequested before the reference time τ, the flow entry requested to thecontroller 300 may be reserved. And the method proceeds to step S252.The flow entry associated with the same flow may be requested after thereference time τ elapses, by a loop of steps S252, S254, and S256.

In step S258, the packet forwarding device 200 may transfer a request ona flow entry associated with the corresponding packet to the controller300.

According to embodiments of the inventive concept, due to the flow entryrequest processing part, it is possible to remove repeated requests forthe same flow of the flow entry requests transported to the controller.Thus, the communication resource may be saved and it is possible toreduce or prevent the load of the controller which is caused byprocessing unnecessary requests.

While the inventive concept has been described with reference to exampleembodiments, it will be apparent to those skilled in the art thatvarious changes and modifications may be made without departing from thespirit and scope of the inventive concept. Therefore, it should beunderstood that the above embodiments are not limiting, butillustrative. Thus, the scope of the inventive concept is to bedetermined by the broadest permissible interpretation of the followingclaims and their equivalents, and shall not be restricted or limited bythe foregoing description.

What is claimed is:
 1. A packet managing method of a packet forwardingdevice, comprising: receiving a packet; extracting flow information fromthe packet; searching a flow entry associated with the packet; searchinga flow entry request table, when a flow entry associated with the packetis not found, to judge whether a request on another flow entrycorresponding to the same flow is transferred to the controller within areference time or not; reserving a request of transmitting the flowentry associated with the packet when a request on the other flow entrycorresponding to the same flow is transferred to the controller withinthe reference time; and transferring the request of transmitting theflow entry associated with the packet to a controller after thereference time, wherein when the request on the flow entry associatedwith the packet is determined to already be transferred to thecontroller once, the request is not repeatedly transferred within areference time.
 2. The packet managing method of claim 1, wherein theflow entry request table includes a flow key field for distinguishing aplurality of flow entries and a timeout time field indicating a transferpoint of time of a flow entry request corresponding to each of theplurality of flow entries.
 3. The packet managing method of claim 2,wherein a sum of a current time and the reference time is recorded atthe timeout time field.
 4. The packet managing method of claim 2,wherein if the requested flow entry is not transferred from thecontroller even when the timeout time elapses, information of the flowis removed from the flow entry request table.
 5. The packet managingmethod of claim 1, further comprising: transferring the flow entryrequest to the controller when the other flow entry requestcorresponding to the same flow does not exist within the reference time.6. The packet managing method of claim 1, wherein the searching a flowentry associated with the packet comprises: processing the packetaccording to a procedure defined in the flow entry if the flow entryassociated with the packet exists.
 7. A packet forwarding devicecomprising: a flow table configured to store a plurality of flowentries; a flow entry request table configured to store a plurality offlow entry requests; a flow search part configured to search a flowentry for a received packet in the flow table; a flow processing partconfigured to process the received packet according to a procedurecorresponding to the searched flow entry; a flow table management partconfigured to manage a flow entry for each of flows in the flow table;and a flow entry request processing part configured to transmit a flowentry request associated with the received packet, to a controller,based on whether the flow entry request corresponding to the same flowexists in the flow entry request table within a reference time withrespect to the received packet that a searching operation of acorresponding flow entry by the flow search part is failed, wherein,when the flow entry request associated with the received packet isdetermined to already be transferred to the controller once, the requestis not repeatedly transferred within the reference time, wherein theflow entry request associated with the received packet is reserved whena request on the other flow entry corresponding to the same flow istransferred to the controller within the reference time; and the flowentry request associated with the received packet is transferred to acontroller after the reference time.
 8. The packet forwarding device ofclaim 7, wherein the flow entry request processing part includes a flowentry request table including a flow key field for distinguishing aplurality of flow entries and a timeout time field indicating a transferpoint of time of a flow entry request corresponding to each of theplurality of flow entries.
 9. The packet forwarding device of claim 8,wherein the flow entry request processing part includes a flow entrysearch module which is configured to determine whether a request for theflow entry is transferred to the controller, based on the flow entryrequest table whenever the request for the flow entry occurs.
 10. Thepacket forwarding device of claim 9, wherein the flow entry requestprocessing part includes a controller communication module which isconfigured to transfer the request for the flow entry to the controllerunder a control of the flow entry search module.
 11. The packetforwarding device of claim 8, wherein the flow entry request processingpart includes a flow entry request table management module which isconfigured to periodically remove timeout entries of the flow entriesexisting in the flow entry request table.